| blob | 7d491bd792cd04e18597bd1a57cade482f45a3e1 |
1 Return-Path: <sentto-365480-746-959272050-mike.carter=redhotant.co.uk@returns.onelist.com>
2 Delivered-To: redhotant¬co¬uk-mike.carter@redhotant.co.uk
3 Received: (qmail 24928 invoked from network); 25 May 2000 16:15:05 -0000
4 Received: from ef.egroups.com (207.138.41.172)
5 by mail.jakinternet.co.uk with SMTP; 25 May 2000 16:15:05 -0000
6 X-eGroups-Return: sentto-365480-746-959272050-mike.carter=redhotant.co.uk@returns.onelist.com
7 Received: from [10.1.10.35] by ef.egroups.com with NNFMP; 25 May 2000 16:27:30 -0000
8 Received: (qmail 20280 invoked from network); 25 May 2000 16:27:29 -0000
9 Received: from unknown (10.1.10.27) by m1.onelist.org with QMQP; 25 May 2000 16:27:29 -0000
10 Received: from unknown (HELO hudson.atuk.aspentec.com) (208.201.95.28) by mta2 with SMTP; 25 May 2000 16:27:28 -0000
11 Received: by hudson.atuk.aspentec.com with Internet Mail Service (5.5.2650.21) id <L41BQJ12>; Thu, 25 May 2000 17:29:51 +0100
12 Message-ID: <40A5DAC1F183D3119DF300805F8BDD32016EC3B4@hudson.atuk.aspentec.com>
13 To: "sdev (E-mail)" <scalos-dev@egroups.com>
14 X-Mailer: Internet Mail Service (5.5.2650.21)
15 From: Michael Carter <michael.carter@aspentech.com>
16 MIME-Version: 1.0
17 Mailing-List: list scalos-dev@egroups.com; contact scalos-dev-owner@egroups.com
18 Delivered-To: mailing list scalos-dev@egroups.com
19 Precedence: bulk
20 List-Unsubscribe: <mailto:scalos-dev-unsubscribe@egroups.com>
21 Date: Thu, 25 May 2000 17:29:50 +0100
22 Reply-To: scalos-dev@egroups.com
23 Subject: [scalos-dev] FW: colourimage icon format
24 Content-Type: text/plain; charset=US-ASCII
25 Content-Transfer-Encoding: 7bit
27 Heres a little gem for you Richard :)
29 -----Original Message-----
30 From: Olaf Barthel [mailto:olsen@sourcery.han.de]
31 Sent: Thursday, May 25, 2000 3:57 PM
32 To: Michael Carter
33 Subject: Re: colourimage icon format
36 On May 25 Michael (Michael Carter) wrote:
38 > Hi Olaf,
39 >
40 > I wounder if you would be willing to help? I'm project manager of Scalos
41 > and we're currently sorting out OS3.5 icon support. However the coder of
42 > the icon datatype has been trying to get everything working and compatible
43 > but is getting peeved with the mess the code is getting opening libaries
44 all
45 > over the place just to read the icon format.
47 Hm... what's the problem? Opening icon.library and calling
48 GetIconTagList()
49 should do the trick, shouldn't it?
51 > We know the new colouricon format is in a IFF structure tacked to the end
52 of
53 > the OS3.5 icons ... but have not tried to work out how to decode it.
54 Would
55 > you be willing to either make some sort of domcument detailing the chunky
56 > encoding or maybe a snippet of source to show how to get the data from the
57 > .info file to a image?
59 Say, why do you need to know this? The icon file format has never been
60 officially documented, which may not have been a good idea, but judging
61 from how it works I can understand why they never documented it (it really
62 is
63 rather embarrassing). So far I didn't write a complete description of
64 the format, so the only way to explain how it works would be by sharing
65 code. Before I can hand out code, I need some sort of authorization. If
66 you can arrange for Amiga, Inc. to nod their heads, I'd be happy to share
67 the reader code with you. Until then, here are my notes on the icon
68 file format:
70 /* The layout of an old icon file (format version 1.1) is as follows:
71 *
72 * <diskobject> ::= (struct DiskObject); 78 bytes
73 * <old-drawerdata> ::= (struct OldDrawerData); 56 bytes
74 * <remaining-drawerdata> ::= the last six bytes of a (struct DrawerData)
75 * <image> ::= (struct Image); 20 bytes
76 * <image-data> ::= UWORD[]; variable number of bytes, depending on image
77 size
78 * <string-len> ::= LONG; 4 bytes
79 * <string> ::= UBYTE[]; variable number of bytes, depending on string
80 length
81 * <number-of-tooltypes> ::= LONG; 4 bytes
82 * <first-image> ::= <image> <image-data>
83 * <second-image> ::= <image> <image-data>
84 * <default-tool> ::= <string-len> <string>
85 * <tool-window> ::= <string-len> <string>
86 * <tooltype> ::= <string-len> <string>
87 *
88 * <old-icon-file> ::= <diskobject> [<old-drawerdata>] <first-image>
89 [<second-image>]
90 * [<default-tool>] [<number-of-tooltypes> <tooltype>+]
91 * [<tool-window>] [<remaining-drawerdata>]
92 *
93 * NOTES:
94 *
95 * - If the icon has drawer data attached, <old-drawerdata> is
96 * mandatory; if the icon's do_Gadget.UserData member's lowest
97 * eight bits (which contain the file format revision number)
98 * are > 0 and <= WB_DISKREVISION, <remaining-drawerdata> must
99 * be present, too.
100 *
101 * - The image data size is computed from the information stored
102 * in the preceding image header; exactly
103 * RASSIZE(image->Width,image->Height) * image->Depth bytes will
104 * be stored. RASSIZE(w,h) computes as ((((w + 15) / 8) & ~1) * h).
105 *
106 * - <number-of-tooltypes> is actually the number of tool types plus
107 * one, multiplied by four, i.e. for six tool type strings to be
108 * stored, <number-of-tooltypes> would be (6 + 1) * 4 = 28. In other
109 * words, there are exactly (<number-of-tooltypes>-1)/4 tool
110 * type strings following <number-of-tooltypes>.
111 * <number-of-tooltypes> may never be 0.
112 *
113 * - <string> always includes the trailing NUL byte. <string-len>
114 * always includes this extra byte, i.e. the string "foo" would
115 * be stored as four bytes and its length would be stored as
116 * four bytes.
117 *
118 * - The contents of <diskobject> define whether <old-drawerdata> and
119 * <remaining-drawerdata>, <second-image>, <default-tool>,
120 * <number-of-tooltypes> and <tooltype>, <tool-window> will
121 * be stored in the file. If do_DrawerData==NULL, <old-drawerdata> and
122 * <remaining-drawerdata> will be omitted; if
123 do_Gadget.SelectRender==NULL
124 * <second-image> will be omitted; if do_DefaultTool==NULL
125 <default-tool>
126 * will be omitted; if do_ToolTypes==NULL <number-of-tooltypes> and
127 <tooltype>
128 * will be omitted; if do_ToolWindow==NULL, <tool-window> will be
129 omitted.
130 *
131 *
132 * The layout of a new icon file is as follows:
133 *
134 * <chunk-id> ::= UBYTE[4]; four upper case 7 bit ASCII characters
135 * <chunk-len> ::= ULONG; four bytes; contents must be an even number
136 * <chunk-bytes> ::= UBYTE[]; variable number of bytes, depending on chunk
137 length;
138 * this must be an even number of bytes
139 * <chunk> ::= <chunk-id> <chunk-len> <chunk-bytes>
140 * <face-id> ::= "FACE"; four bytes
141 * <face-contents> ::= (struct FaceChunk); 4 bytes
142 * <face-chunk> ::= <face-id> <chunk-len> <face-contents>
143 * <image-id> ::= "IMAG"; four bytes
144 * <image-header> ::= (struct ImageChunk); 8 bytes
145 * <image-palette> ::= UBYTE[]; variable number of bytes, depending on
146 * palette size
147 * <image-data> ::= UBYTE[]; variable number of bytes, depending on
148 * image size
149 * <image-chunk> ::= <image-id> <chunk-len> <image-header> <image-data>
150 [<image-palette>]
151 * <form-id> ::= "FORM"; four bytes
152 * <icon-id> ::= "ICON"; four bytes
153 *
154 * <new-icon-file> ::= <old-icon-file> <form-id> <chunk-len> <icon-id>
155 * <face-chunk> <image-chunk> [<image-chunk>] <chunk>*
156 *
157 * NOTES:
158 *
159 * - The new icon data structures immediately follow the old icon data
160 * structures; the new data is more or less stored in straight IFF
161 * format, the only difference being that the IFF structure need not
162 * begin at an even offset into the file. There are no version or revision
163 * indicators or magic numbers in the icon file to tell the reader that
164 * there is new data following the old icon format. The reader just tries
165 * to read the data and makes the best of what follows.
166 *
167 * - The chunk contents must always be an even number of bytes long.
168 * If necessary, pad bytes are added.
169 *
170 * - The <chunk-len> of the initial "FORM" chunk contains the
171 * number of bytes to follow <old-icon-file> minus 8 bytes
172 * (used by <form-id> and <chunk-len>).
173 *
174 * - The IMAG chunks contain both the header information and the
175 * pixel and palette data. Immediately following the header
176 * there will be ic_NumImageBytes+1 bytes of image data. If the
177 * ICF_HasPalette flag is set in the ic_Flags member, exactly
178 * ic_NumPaletteBytes+1 number of palette bytes will follow the
179 * pixel data, otherwise, there will be 0 bytes of palette
180 * information and the contents of ic_NumPaletteBytes will
181 * be ignored.
182 *
183 * - The first image stored in an IMAG chunk must have palette
184 * information. If the second image has no palette stored
185 * with it, it will use the palette of the first image.
186 *
187 * - Palette and image data may be stored in compressed format.
188 * The only compression algorithm supported so far is the run
189 * length encoding method known as "ByteRun1" as used by the
190 * IFF-ILBM format. Data may be stored in compressed format only
191 * if compression actually resulted in space savings. The
192 * ByteRun1 compression method operates on pixels with the number
193 * of significant bits taken into account. This means, for example,
194 * that if the pixel data contains only colours in the range 0..15
195 * that there are four significant bits. The compressor will then
196 * pack the four bit pixel values into bytes.
197 *
198 * - In the FACE chunk, the image aspect ratio information is encoded
199 * into a single byte. The upper four bits contain the X aspect value,
200 * the lower bits contain the Y aspect value, i.e. a ratio of 1:2 would
201 * be encoded as 0x12.
202 *
203 * - The image size given in the FACE chunk need not agree with the
204 * data stored in the DiskObject do_Gadget.Width/do_Gadget.Height
205 * members since the loader will automatically adjust these values
206 * acording to the actual image size being used. If no new icon data
207 * is stored with a file, the loader will default to use the size of
208 * the first <image> found.
209 */
211 --
212 Home: Olaf Barthel, Brabeckstrasse 35, D-30559 Hannover
213 Net: olsen@sourcery.han.de (Home), olsen@logicalline.com (Work)
215 ------------------------------------------------------------------------
216 Best friends, most artistic, class clown Find 'em here:
217 http://click.egroups.com/1/4054/0/_/647280/_/959272050/
218 ------------------------------------------------------------------------
220 .-----------------------------------------------.
221 http://scalos.satanicdreams.com